Release 10.1A: OpenEdge Application Server:
Developing AppServer Applications

Choosing a session model

The session model you choose determines how the AppServer services clients, and that choice depends on the type of application you want to support.

Session-managed model

The session-managed model is specifically designed for application services or Web services that support a single transaction across multiple requests from the same client, returning intermediate results with each request until the transaction is completed. Thus, the AppServer maintains context between requests for each client that it services, and each such client participates in a persistent connection to the Appserver. The connected AppServer is dedicated to serving that one client until the connection between them is terminated.

In this session model, all client requests are single-threaded, meaning that the AppServer does not handle another request from the same client until it has completed and responded to any pending request from that client.

Session-free model

The session-free model is specifically designed for application services or Web services that return a complete result, starting and ending any transactions, in a single request. Thus, the AppServer maintains no context for any client that it services. Requests from a session-free client are handled by any available AppServer (and AppServer agent) that supports the required application service. The session-free client (or the Web Services or OpenEdge Adapter for Sonic ESB on behalf of Web service clients) manages a pool of physical AppServer connections (the ) that provides access to the session-free AppServers available to service client requests. Thus, a session-free AppServer executes requests from all clients as it receives them, and completes each request independently of any prior request (see the "State-free operating mode" section).

In this session model, all requests from a client are multi-threaded, meaning that multiple requests from a single client can be executed in parallel, as AppServer resources permit. The more AppServers (and AppServer agents) that are available (through a NameServer) to handle requests for a given application service (or Web service), the more requests that the application or Web service can handle simultaneously from a single client. Each session-free AppServer executes requests as fast as communications and AppServer agent resources permit. Thus, the same client can have multiple requests executed by an AppServer at one time, and each AppServer can execute requests from any number of clients at one time, both limited by the number and extent of AppServer agents configured for each AppServer.

Making the final choice

As an aid to choosing a session model, Table 1–1 shows major points of comparison between the session-free and session-managed models.

Table 1–1: Session-free and session-managed models compared

Point comparison	Session-free	Session-managed
AppServer operating mode	Supported by the state-free operating mode.	Supported by the state-aware, state-reset, and stateless operating modes.
AppServer application programming model	Every application service or Web service request is independent of every other request. No session context is maintained between the client and the AppServers involved in the requests. The use of remote persistent procedure instantiation and other connection-based interfaces (SubAppObjects and ProcObjects) is not recommended. The use of connect and disconnect procedures in the AppServer configuration is not allowed.	Every application service or Web service request is associated with a single connected client and AppServer. Session context for that client can be maintained by the AppServer across client requests.
Compatibility with different OpenEdge clients	Compatible with all OpenEdge clients, including Web service clients supported by the WSA (or OpenEdge Adapter for Sonic ESB) and Internet clients supported by the AppServer Internet Adapter (AIA).	Compatible with all OpenEdge clients, including Web service clients supported by the WSA (or OpenEdge Adapter for Sonic ESB) and Internet clients supported by the AppServer Internet Adapter (AIA).
Client connection model	The client application does not physically connect to or disconnect from an AppServer. The client logically connects to an application service or Web service and simply sends requests to any available AppServer and handles the responses from wherever they are sent.	Before sending any other Web service request, the client application must first establish a physical connection to a single AppServer instance through an application service or Web service it wants to access. Once a physical connection is established, the AppServer can maintain session context for the client and application service, but for a Web service, both the Web service client and the Web service must maintain awareness of the physical connection using SOAP headers. The client developer must program the handling of these headers in the client application.
Communications between client and AppServer	Clients of the AppServer exchange messages transparently with any available AppServer resource using a pool of physical AppServer connections (connection pool) maintained by the WSA and OpenEdge Adapter for Sonic ESB for Web services and maintained by the client session for all other clients. Thus, AppServer resources handle all client requests in parallel, depending on the resources available.	Each client of the Web service creates a separate and exclusive connection over which all messages are exchanged with a particular AppServer resource until the connection is terminated. Thus, the AppServer resource handles each client request in sequence, executing each request only after the previous request from the client has completed.

Thus, if your application requires the AppServer to manage context for its clients, choose a session-managed operating mode (stateless, state-aware, or state-reset). Also, if you are Web service-enabling an existing AppServer application that relies on a specific operating mode, you must continue to use that mode for the Web service unless you make the necessary changes in the application to use another operating mode.

If your application requires no context management on the AppServer and otherwise has no programming dependency on a session-managed operating mode, you can choose the session-free operating mode (state-free). For an existing session-managed AppServer application that meets these requirements (maintains no context), you can immediately change the AppServer operating mode to state-free with no code changes, thus converting the entire application to a session-free model with potentially greater performance benefits.

Note: If you do convert an existing AppServer application from the session-managed to the session-free model, be sure to set any AppServer instances that support the same application service to the state-free operating mode.

If you can use the session-free operating model, it has the following advantages over the session-managed model:

Both application services and Web services scale much more readily compared to session-managed.
The programming model for session-free applications—for the AppServer application and for the client application—is simpler than for session-managed applications.

For more information on programming:

Session-free and session-managed AppServers, see Chapter 2, " Programming the AppServer."
Session-free and session-managed Progress 4GL clients, see Chapter 3, " Programming Progress 4GL Client Applications."
Session-free and session-managed Open Clients, see OpenEdge Development: Open Client Introduction and Programming .
Session-free and session-managed Web service clients of Progress 4GL Web services, see OpenEdge Development: Web Services .
Note: If your aim in choosing the session-free model is greater scalability and performance, and you also require secure connections, note that using either (or both) the AIA with HTTPS or an SSL-enabled AppServer tends to incur heavy performance penalties regardless of the session model that you choose. For more information, see the sections on security considerations in Chapter 4, " Design and Implementation Considerations."

Whatever session model your AppServer application supports, you must also perform these tasks for a Web service:

Specify the same session model for any Web service definition based on the same application service. For more information on specifying the session model for a Web service definition using ProxyGen, see OpenEdge Development: Open Client Introduction and Programming .
Manage the Web service through the WSA (or OpenEdge Adapter for Sonic ESB) according to the same session model. For more information on managing Web services for a given session model, see the chapters on Web service management and deployment in OpenEdge Application Server: Administration .